build(deps): keep nodes running and get test results sooner - #1447

Description

The node pins kwil-db at 6608a4cc. This moves the pin to 284bfd01, the head of kwil-db main, which adds the four pull requests merged there since:

• chore: get schema test results sooner, even after a stall kwil-db#1775: the schema test harness replaces a test database that has not reported ready within 60 seconds, and fails the test if the second one does not report ready either. It used to wait until the two hour package timeout. It also removes each test database with its volume. After each schema change, a node reloads the table metadata with a query that takes about 21 ms on a schema the size of the node's, instead of about 258 ms.
• fix(node): keep nodes up when sent an incomplete transaction kwil-db#1776: a node refuses a transaction that lacks its body, its fee or its signature with code 1, malformed transaction, whether a client broadcasts it or a peer announces it.
• chore(node): keep a node that skipped ahead in sync kwil-db#1777: a node that restores a newer snapshot under resync_when_behind keeps the replica identity the snapshot gives each table, so the blocks it applies after the restore reach the network's app hash.
• chore(node): retry a block that failed to execute kwil-db#1778: when a sentry, or any node in catch-up, fails to execute a committed block, it rolls the block back and applies it again, up to three times, and stops if the block still fails. It used to stop at the next attempt with block N already processed.

The slow integration tests run every test on that harness. A test database that stalls now costs its test a minute, where it held its job for two hours and then made the job's retry rerun all of its packages. Applying the node's migrations and seed data to a test database took about 22 seconds and now takes about 5, because most of that time went to the reload.

Before the release

• Executing a block gives the same results as before. The new reload query returns the same tables as the old one, which the first pull request above checked with reflect.DeepEqual on every namespace of a database holding the node's migrations. The second pull request changes only how a node admits transactions.
• The third changes what a restore produces only when it restores into a database kwild has already opened, which happens only with resync_when_behind above 0. The restored tables then get the replica identities a new node gets from the same snapshot, so the node hashes deletes and updates as the network does.
• The fourth changes only what a node does after a block fails to execute. A fatal database error still stops the node at once. A block applied again can still run to another app hash, when the failed attempt left something in the memory of the interpreter or an extension, such as a table the block created. The node then stops, and its log says that a restart replays the block.
• The four add no config key, migration or p2p protocol.
• kwil-db/core changes only in core/types: the new ErrMalformedTx and its mapping to and from code 1. The node's own code calls neither mapping function.

Related Problem

• resolves: Problem: developers can't get node PR checks back within an hour #1445

How Has This Been Tested?

• go build ./... and go vet -tags kwiltest ./... are clean with Go 1.25.3, the version CI and the Dockerfile use.

• The go.mod diff is the two kwil-db lines, and go mod tidy changed nothing else.

• The 42 packages that CI tests on a pull request, 25 of them with tests, pass locally with the same go test -failfast -p 1 -count=1 -tags=kwiltest command.

• On one node built from this branch, user.broadcast with an empty transaction got code 1, malformed transaction: no body. user.broadcast without a transaction and user.estimate_price without a body got invalid params. The node went on producing blocks.

• The slow integration tests do not run on a pull request that changes only go.mod, so I started them on this branch by hand. All three jobs passed on their first attempt. order_book took 23m15s, streams 16m22s and rest 25m31s, and the whole run 25m36s. On the previous pin the same jobs took 41m28s, 42m46s and 50m25s, and the whole run 50m29s, in the run linked from the pull request that split them into three jobs. Twice in this run a test database did not report ready within a minute, in TestRequestAttestationFees and in TestQueries. The harness replaced it each time, and both tests passed.

  • https://github.com/trufnetwork/node/actions/runs/38354005136
  • ci: get slow integration test results back sooner #1446